If we can @xrstf, I would love to add a code-comment on why we have a custom loader

I would love to add a code-comment on why we have a custom loader

a) If you want a comment, add one? :D

b) What custom loader? Are we not using the regular client-go loader?

I would love to add a code-comment on why we have a custom loader

a) If you want a comment, add one? :D

b) What custom loader? Are we not using the regular client-go loader?

a) I would love to, but I don't know why we have it and I would really like to know from you :D Hence I cannot.

b) As stated here #111 (comment), I don't fully know why we are using a custom (super similar) loader and not clientcmd.BuildConfigFromFlags directly.

Okay let's not get hung up on this comment thing. The PR itself is fine, just needs a rebase.

We are not using a "custom loader". We're just using standard client-go stuff. I chose this over one of the helpers like BuildConfigFromFlags or ctrl-runtime's GetConfigOrDie because I personally do not like the magicness of client-go's --kubeconfig flag and would rather use a more explicit route. That's all there is. It's not meant to do anything special, I just did not like BuildConfigFromFlags warning logs and messages when the kubeconfig is borked, because those messages are geared towards --kubeconfig (which is not the flag that is relevant here) and it also defaults to falling back to the in-cluster config, something I also do not want for the kcp kubeconfig. :)

/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: xrstf

The full list of commands accepted by this bot can be found here.

The pull request process is described here

resolved the merge conflict

/lgtm

LGTM label has been added.